1. Technical Field
The invention relates to a method and mobile node for discovering a home agent serving a mobile node upon the mobile node changing its mobility management scheme in a packet-switched network. Furthermore, the invention relates to a home agent supporting the mobile node in discovering its serving home agent upon changing the mobility management scheme.
2. Description of the Related Art
Communications systems evolve more and more towards an Internet Protocol (IP)-based network. They consist of many interconnected networks, in which speech and data is transmitted from one terminal to another terminal in pieces, so-called packets. Packets are routed to the destination by routers in a connection-less manner. Therefore, IP packets consist of IP header and payload information and the header comprises among other things source and destination IP address. For scalability reasons a large IP network is usually divided in subnets and uses a hierarchical addressing scheme. Hence, an IP address does not only identify the corresponding terminal, but additionally contains location information (current subnet) about this terminal. Typically this location information is also referred to as the prefix of the IP address. With additional information provided by routing protocols, routers in the packet-switched network are able to identify the next router towards a specific destination.
If a terminal is mobile, a so-called Mobile Node (MN), and moves between subnets, it must change its IP address to a topological correct address using the prefix of the subnet (domain) because of the hierarchical addressing scheme (if no other mechanism is provided allowing the mobile node to keep its address—see the discussion of Proxy Mobile IP below). However, since connections on higher-layers such as TCP connections on the transport layer of the OSI model are defined with the IP addresses (and ports) of the communicating nodes, the connection breaks, if one of the nodes changes its IP address, e.g., due to movement.
Mobile IPv6
Mobile IPv6 (MIPv6) as specified by Johnson et al., “Mobility Support in IPv6”, IETF RFC 3775, June 2004 (available at http://www.ietf.org and incorporated herein by reference) is an IP-based mobility protocol that enables mobile nodes to move between subnets in a manner transparent for higher layers and applications, i.e., without breaking higher-layer connections. Therefore, a mobile node has two IP addresses configured: a care-of address (CoA) and a home address (HoA). The mobile node's higher layers use the home address for communication with the communication partner, who is associated with the destination terminal, the so-called corresponding node (CN). This address does not change and serves the purpose of identification of the mobile node. Topologically, the home address belongs to the home network (HN) of the mobile node.
In contrast, the care-of address changes on every movement that results in a subnet change (new prefix being advertised) and is used as the locator for the routing infrastructure. Topologically, the care-of address belongs to the network the mobile node is currently attached to. One out of a set of anchors, so-called home agents (HA), located on the home link maintains a mapping of the mobile node's care-of address to mobile node's home address and redirects incoming traffic for the mobile node to its current location. Reasons for having a set of home agents instead of a single home agent are redundancy and load balancing.
Mobile IPv6 currently defines two modes of operation: bi-directional tunneling and route optimization. If bi-directional tunneling is used, data packets sent by the corresponding node and addressed to the home address of the mobile node are intercepted by the home agent in the home network and tunneled to the care-of address of the mobile node. Data packets sent by the mobile node are reverse tunneled to the home agent, which decapsulates the packets and sends them to the corresponding node. For this operation, the home agent must be informed about the current location (i.e., the care-of address) of the mobile node. Therefore, the mobile node sends location updates messages, which are called binding update (BU) messages in MIPv6, to the home agent. Binding update messages contain a sequence number, so that the home agent can identify the freshness and correct ordering of binding update messages. These binding update messages are sent over an IPsec security association and thus are cryptographically protected to provide data origin authentication and integrity protection. This requires that mobile node and home agent share a secret key. Hence, the home agent only accepts binding update messages for the mobile node's home address that are cryptographically protected with the corresponding shared key.
Extensions to Mobile IPv6
Recently, Mobile IPv6 has been extended to enable mobile nodes to dynamically bootstrap with home agents (see Giaretta et al., “Mobile IPv6 bootstrapping in split scenario”, RFC 5026, October 2007, available at http://www.ietforg and incorporated herein by reference). Bootstrapping includes discovering a home agent, setting up the security associations with the home agent for securing the Mobile IP signaling and configuring a corresponding home address.
An IPsec security association may be dynamically established using IKEv2. IKEv2 is defined in Kaufman, “Internet Key Exchange (IKEv2) Protocol”, IETF RFC 4306, December 2005; Arkko et al., “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents”, IETF RFC 3776, June 2004 and Devarapalli et al., “Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture”, IETF RFC 4877, April 2007 (all three documents being available at http://www.ietforg and being incorporated herein by reference). Another protocol allowing the establishment of a security association for securing the Mobile IP signaling is the authentication protocol by Patel et al., “Authentication Protocol for Mobile IPv6”, IETF RFC 4285, January 2006, available at http://www.ietf.org and incorporated herein by reference.
Multiple methods exist for discovering a home agent by the mobile node: One option is that the mobile node is pre-configured with a DNS name for the home agent and queries DNS (Domain Name System) to get a list of home agent IP addresses (see Giaretta et al., “Mobile IPv6 bootstrapping in split scenario”, RFC 5026, October 2007 available at http://www.ietf.org and incorporated herein by reference). Another option is that the mobile node is pre-configured with an anycast home agent address suffix and sends an DHAAD message (see IETF RFC 3775) or an IKE_SA_INIT message via anycast to a group of home agents (see Dupont et al., “IKEv2-based Home Agent Assignment in Mobile IPv6/NEMO Bootstrapping”, IETF Internet Draft, draft-dupont-ikev2-haassign-02.txt, January 2007 available at http://www.ietforg and incorporated herein by reference). The prefix for the anycast home agent address can be pre-configured on the mobile node or dynamically obtained from the network. Further, it can be equal to the mobile node's home address prefix.
With the anycast concept, multiple home agents have the same anycast address assigned and a message sent to this anycast is delivered to any of the home agents that are part of the anycast group. Typically the message is delivered to the home agent that is located closest to the sender. DNS-based and anycast-based home agent discovery can also be combined. Therefore, the mobile node is pre-configured with a DNS name and DNS returns an anycast address. FIG. 1 shows an example of home agent discovery using IKE anycasting.
In a deployment scenario, where the access network operator and the home network operator are the same or have a trust relationship, a home agent address for the mobile node can be assigned by the home or visited network, delivered to the access network via the AAA protocol and assigned to the mobile node using the DHCP protocol. With this approach, the mobile node queries the DHCP server to obtain a home agent IP address (see Chowdhury et al., “MIP6-bootstrapping for the Integrated Scenario”, IETF Internet Draft, draft-ietf-mip6-bootstrapping-integrated-dhc-05.txt, June 2007 and Hee Jin Jang et al., “DHCP Option for Home Information Discovery in MIPv6”, IETF Internet Draft, draft-ietf-mip6-hiopt-10.txt, January 2008 both available at http://www.ietforg and incorporated herein by reference).
Client-Based Versus Network-Based Mobility Management
Mobile IP is a host- or client-based protocol, since the mobility management signaling is between the host/client and the home agent. Hence, MIP is also sometimes called Client Mobile IP (Client MIP or CMIP).
Another approach becoming popular is a network-based approach for IP mobility management. An entity in the visited access network acts as a proxy for the mobile node and manages the mobility for the mobile node, including the signaling of location updates to the home agent. Network-based mobility management is considered to have some advantages like less signaling overhead over the air and mobility support for simple IP nodes (i.e., non-Client MIP-capable nodes). A commonly identified drawback is that it requires support from the visited access network.
The IETF (Internet Engineering Task Force) is working on such approach for localized mobility management based on the Mobile IP protocol. Since a network entity is acting as a proxy on behalf of the mobile node, the protocol is called Proxy Mobile IP (Proxy MIP or PMIP). There are variants for IPv6 called PMIPv6 (see Gundavelli et al., “Proxy Mobile IPv6”, IETF Internet Draft, draft-ietf-netlmm-proxymip6-10.txt, February 2008, available at http://www.ietf.org and incorporated herein by reference) and variants for IPv4 called Proxy MIPv4 (see Leung et al., “WiMAX Forum/3GPP2 Proxy Mobile IPv4”, IETF Internet Draft, draft-leung-mip4-proxy-mode-07.txt, February 2008 available at http://www.ietf.org and incorporated herein by reference).
PMIPv6 introduces a new logical entity called mobile access gateway (MAG), which is typically co-located with the access router (AR) the mobile node is currently attached to and which sends binding update messages on behalf of a mobile node. The Proxy MIP-home agent is an extended Client MIP-home agent anchor and is called local mobility anchor (LMA). Since a local mobility anchor includes home agent functionality, the local mobility anchor is sometimes also denoted a home agent herein. Binding update messages sent by the mobile access gateway are marked with a flag, so that they can be identified as proxy binding update (PBU) messages by the local mobility anchor and can be distinguished from binding update messages sent by the mobile node (i.e., CMIP signaling messages).
Furthermore, proxy binding update messages contain, among others, a network access identifier (NAI) option, a home prefix option, and a timestamp option. The NAI option contains the NAI (as specified in Aboda et al., “The Network Access identifier”, IETF RFC 4282, December 2005, available at http://www.ietf.org and incorporated herein by reference) of the mobile node, which has the form of “username@realm” and which is used to identify the mobile node.
The home prefix option contains the home address or home prefix of the mobile node. In Proxy MIPv6, every mobile node typically gets a unique prefix assigned. When the mobile node attaches to a new mobile access gateway, the mobile access gateway sends a proxy binding update to the local mobility anchor to register the mobile node's new location. The proxy binding update can be triggered, e.g., by a successful network authentication, by DHCP (Dynamic Host Configuration Protocol) messages or others. Further, the mobile access gateway announces the mobile node's home prefix to the mobile node. Consequently, the mobile node's IP stack thinks it is at home as long as it moves within the Proxy MIP domain and does not notice that it changes subnets. A tunnel between local mobility anchor and mobile access gateway is established and all traffic from/to the mobile node is forwarded through this tunnel.
The 3GPP SAE system (see 3GPP TS 23.401, “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”, version 8.0.0 and 3GPP TS 23.402, “Architecture enhancements for non-3GPP accesses”, version 8.0.0 both available at http://www.3gpp.org and incorporated herein by reference) specifies both (Client) MIPv6 and Proxy MIPv6 for mobility management for handovers between access technologies. The home agent and local mobility anchor functions are part of the public data network gateway (PDN-GW), the mobile node functions are part of the user equipment (equivalent to a mobile node) and the mobile access gateway functions are part of the evolved Packet Data Gateway (ePDG), access gateway and access routers of non-3GPP networks. The equivalent terms are used inter-changeably in the following.
The 3GPP SAE system defines different types of access networks: a 3GPP access network provides network access to the terminal using 3GPP radio technologies like GSM/GPRS, UMTS, LTE, whereas a non-3GPP access network provides network access using non-3GPP radio technologies like WLAN, WiMax, CDMA2000, etc. Non-3GPP access networks can further be divided in trusted and un-trusted non-3GPP access networks, depending on the level of trust by a 3GPP operator. A terminal located in a trusted non-3GPP access network can directly access 3GPP services like the Mobile IPv6 service provided by the PDN-GW, whereas a terminal located in a untrusted non-3GPP access network may only access 3GPP services when over an ePDG. The ePDG is similar to a VPN server in the sense that the terminal first needs to authenticate at the ePDG and then all the traffic to/from the terminal is sent integrity and confidentiality protected over a secure IPsec tunnel to the ePDG. A terminal typically discovers an ePDG address using DNS and sets up the IPsec tunnel using IKEv2.
It is possible that some access networks support PMIP and others do not. Hence, the mobility management for a mobile node can transition from PMIPv6 to MIPv6 or vice versa during a session. If a mobile node transitioning from a domain with network-based mobility management to a domain with host-based mobility management, the mobile node needs to discover and register with the anchor (home agent) that was used before by the network in order to be able to ensure session continuity. Since the mobile node is typically unaware of its home agent when the mobility is managed by the network, the mobile node needs to discover the specific home agent as quickly as possible in order to prevent noticeable interruptions in the data service, at least if the discovery cannot be done before the handover in a predictive way, e.g., because the mobile node suddenly ran out of coverage. Furthermore, it should not be possible for a node to identify the home agent that serves another mobile node. Otherwise, an off-path attacker can mount targeted denial of service (DoS) attacks against the home agent of a specific mobile node.